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DETAILED ACTION 
Response to Arguments 
The Examiner acknowledges the Applicant's amendments to claim 22. Regarding this 
claim, the Applicant argues that Dara-Abrams et al. (U.S. Patent No. 6,456,892, hereafter 
referred to as "Dara-Abrams"), presented in the previous Office Action, fails to disclose or 
suggest linking and building source code to have an application with a command-set unaware 
GUI, to execute remotely from a remote device, with a command-set aware user interface 
running beneath it, also remotely from the remote device. The Examiner respectfully disagrees 
with this argument. Dara-Abram clearly teaches linking and building source code to have an 
application with a command-set unaware GUI, which executes remotely from a remote device, 
with a command set aware user interface running beneath it, as described in the previous Office 
Action. Dara-Abrams does not explicitly teach that the command set aware user interface, i.e. 
the DDI Target, may run remotely from the remote device. However, given the broadest, most 
reasonable interpretation of the independent claims, it is unclear as to whether the command-set 
aware user interface runs remotely from the remote device. Claim 22, for example, states 
"building the source code for the command-set unaware GUI with the linked source code for the 
command-set aware user interface to result in the device management application having the 
GUI with the command-set aware user interface running beneath the GUI, remotely from the 
remote device, the GUI having the graphical component to provide access to the associated 
configuration command." It is unclear as to whether the phrase, "remotely from the remote 
device" refers to the command set aware user interface running beneath the GUI, or to the GUI 
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having the graphical component to provide access to the associated configuration command. The 
Applicant's arguments have thus been fully considered, but are not persuasive. 



Claim Rejections - 35 USC § 112 
The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

Claims 32-36 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. In claim 32, there is no antecedent basis for "the remote device." As claims 33-36 
depend on claim 32, and include all of the limitations of claim 32, claims 33-36 are also rejected 
for this reason. 
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Claim Rejections - 35 USC §102 
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 2 1 (2) of such treaty in the English language. 

Claims 22-30, 32-35, and 37-40 are rejected under 35 U.S.C. 102(e) as being anticipated 
by U.S. Patent No. 6,456,892, which is attributed to Dara-Abrams et al. (and hereafter referred to 
as "Dara-Abrams"). In general, Dara-Abrams describes a system by which a device, referred to 
as a "DDI controller," generates and displays a graphical user interface that is used to manage 
and control a remotely-located device, which is referred.to as a "DDI target" (for example, see 
column 4, line 35 - column 5, line 23). 

Specifically regarding claims 22, 25-28, and 30, Dara-Abrams teaches developing and 
generating a graphical user interface (GUI), which is executed and displayed at the DDI 
controller (for example, see column 4, line 59 - column 5, line 8; column 6, line 60 - column 7, 
line 27; and column 11, line 66 - column 12, line 24). Dara-Abrams discloses that the DDI 
controller is not required to have any advanced-knowledge of the functionality or 
implementation of the DDI target device to display this GUI (see column 7, lines 27-48; and 
column 10, lines 48-67, for instance). Instead, the DDI controller delivers messages to the DDI 
target regarding the user's interaction with the GUI, wherein response, the DDI target interprets 
these messages and executes various functionality, possibly updating the state of the DDI target 
and also the display of the GUI (see column 12, line 38 - column 13, line 34; and column 19, 
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line 53- column 20, line 44). Dara-Abrams is consequently considered to teach developing 
source code, presumably with a graphical programming language environment, for a command- 
set unaware GUI with a graphical programming language, the GUI to be executed at a DDI 
controller, remotely from a DDI target. Moreover, Dara-Abrams discloses that the DDI target 
similarly comprises a user interface (for example, see column 3, lines 57-67), whereby it is 
understood that the logic used to implement this user interface is used to execute the DDI target 
functions in response to the aboverdescribed messages received from the DDI controller (for 
example, see column 7, lines 27-48; and column 12, line 38 - column 13, line 8). Dara-Abrams 
is consequently also considered to teach developing source code, with a graphical programming 
language environment, for this command-set aware user interface, the source code to be used to 
generate the user interface to execute at the remotely-located DDI target to configure a 
configuration parameter of the DDI target according to a configuration parameter of the 
command set. Additionally, Dara-Abrams is considered to teach linking the source code for the 
command-set aware user interface in the source code for the command-set unaware GUI to 
provide a graphical component in the GUI associated with a configuration command. Dara- 
Abrams particularly discloses that an API is used to program the DDI controller to communicate 
with the DDI target, specifically to send messages to the target, which result in the target 
executing various commands, and to receive status updates from the target (for example, see 
"TABLE II" in column 22; and column 37, line 19 - column 38, line 59). Therefore, and with 
specific regard to claims 25-28, Dara-Abrams teaches providing a code hook, particularly an 
API, in the source code for the GUI to the DDI target. Such an API is understood to comprise a 
library of functions (for example, see "TABLE II" in column 22; and column 37, line 19 - 
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column 38, line 59), which are referenced in the source code of the DDI controller's GUI. Each 
of these functions is considered a macro, like that of claims 27 and 28, which references an 
object-oriented class object in the source code of the GUI, the class object used to send messages 
to the DDI target, and consequently to invoke a routine of the source code of the DDI target. 
Also, since the target device executes various functionality in response to messages received 
from the DDI controller, the DDI target is considered to run "beneath" the DDI controller, and 
consequently, Dara- Abrams is considered to teach building the source code for the command-set 
unaware GUI with the linked source code for the command-set aware user interface to result in a 
device management application having the GUI with the command set aware user interface 
running beneath the GUI, remotely from the remote device, the GUI having the graphical 
component to provide access to the associated configuration command. It is understood that the 
source code for the GUI, along with APIs linked to the source code for the DDI target device, are 
compiled to generate an executable binary device management application, like recited in claim 
30. Dara-Abrams discloses that the DDI controller comprises a processor to process such source 
code (see column 9, lines 43-63). As is known in the art, the source code is necessarily 
translated into executable binary code so that the processor may understand the code. 
Consequently, Dara-Abrams is understood to teach a method, like that recited in claims 22, 25- 
28, and 30, which is for developing a device management application to manage a remote device. 

Concerning claims 23 and 24, Dara-Abrams discloses that the DDI target, not the DDI 
controller, comprises the functionality to implement the various features of the target device, and 
to determine each of the states of the target device which occur in response to the executed 
features (see column 7, lines 27-48, for example). It is therefore understood that the user 
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interface of the DDI target necessarily comprises code to execute every configuration command 
needed to generate every configuration state of the DDI target, like recited in claim 23. 
Specifically concerning claim 24, Dara-Abrams discloses that the DDI target maintains 
information regarding the configuration state of the DDI target device, and ascertains a new state 
of the device occurring in response to commands executed by the DDI target device (for 
example, see column 7, lines 27-48; column 12, line 60 - column 13, line34; and column 20, 
lines 23-45). It is therefore understood that the DDI target necessarily comprises one or more 
variables, data structures, or functions defining these configuration states of the DDI target, 
whereby such variables, data structures, or functions are configured according to commands 
executed at the DDI target. 

With respect to claim 29, the source code for the DDI target interface is considered to be 
re-used, as it is linked it to the source code for the DDI controller's GUI, as is described above, 
and thus does not require the GUI's source code to comprise the same or similar code as the DDI 
target interface. Additionally, as Dara-Abrams discloses that this code for DDI target may be 
stored in ROM (see column 10, lines 18-27), it is understood that source code for the DDI target 
interface may comprise firmware. Dara-Abrams thus teaches that the source code for the DDI 
target interface may comprise firmware defining the user interface, whereby this firmware is re- 
used by linking it to the source code of the DDI controller's GUI defining a device management 
application. 

As per claim 32, Dara-Abrams describes source code defining a user interface, 
considered a "console user interface" like the present application, which as described above, is 
generated and executed at a remote network device. Dara-Abrams discloses that the remote 
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device, i.e. DDI target, maintains information regarding its configuration state, and ascertains a 
new state of the device occurring in response to commands executed by the DDI target device 
(for example, see column 7, lines 27-48; column 12, line 60 - column 13, line34; and column 20, 
lines 23-45). It is therefore understood that the DDI target necessarily comprises one or more 
variables, data structures, or functions, collectively considered a "configuration kernel" like that 
of the present application, which define the configuration state of the DDI target, and which are 
configured according to commands executed by the DDI target. Such commands may be 
performed in response to user interaction with the console user interface of the DDI target, or in 
response to user interaction with a GUI of a device management application executing at a DDI 
controller (for example, see column 14, lines 28-41; and column 20, lines 14-44). Regarding this 
GUI, Dara-Abrams teaches that such a GUI is defined by source code comprising a hook, 
namely an API, which references the source code of the console user interface of the DDI target 
in order to provide a graphical component in the GUI to operate a function of the remote device 
and access a configuration command from the GUI, as is described above. As further described 
above, the user interface of the DDI target is considered to run "beneath" the GUI of the DDI 
controller, since the target device executes various functionality in response to messages 
received from the DDI controller GUI. Dara-Abrams is consequently considered to teach: 
receiving source code defining a console user interface (CUI) to generate a CUI to execute at a 
network device, the CUI to configure a configuration kernel (CK) of the network device 
according to a configuration command; receiving source code defining a GUI to generate a 
device management application, the GUI to be executed at a management point remote from the 
network device, the source code for the GUI to include a hook to the source code for the CUI to 
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provide a graphical component in the GUI to operate a function of the GUI to access the 
configuration command from the GUI; and building the source code for the GUI with the hook to 
the source code for the GUI to create the device management application having the CUI running 
under the GUI, remotely from the remote device, the GUI having the graphical component to . 
provide access to the associated configuration command. Accordingly, the development of such 
source code is understood to necessitate an article of manufacture comprising a computer- 
readable medium having instructions to cause a computer to perform operations like recited in 
claim 32. 

As per claims 33 and 34, Dara-Abrams teaches providing a code hook, particularly an 
API, in the source code for the GUI to the source code for the CUI of the DDI target, as is 
described above. Such an API is understood to comprise a library of functions, each associated 
with a particular class, and each relating to a message sent between the GUI and the DDI target 
(for example, see "TABLE II" in column 22; and column 37, line 19 - column 38, line 59). 
Dara-Abrams thus teaches providing source code defining the CUI as a library to the source code 
defining the GUI, wherein the source code for the GUI includes a hook to the source code for the 
CUI by including a reference to a class defined in this library, particularly, a function of a class 
defined in the library. Each of these functions is considered a macro, like that recited in claim 
33, which references the source code of the CUI. 

With respect to claim 35, the source code for the DDI target CUI is considered to be re- 
used, as it is linked it to the source code for the DDI controller's GUI, and thus does not require 
the GUI's source code to comprise the same or similar code as the DDI target CUI, as described 
above. Additionally, as Dara-Abrams discloses that the code for DDI target may be stored in 
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ROM (see column 10, lines 18-27), it is understood that source code for the DDI target CUI may 
comprise firmware. Dara-Abrams thus teaches that the source code for the DDI target CUI may 
comprise firmware defining the user interface, whereby this firmware is re-used by linking it to 
the source code of the DDI controller's GUI defining a device management application. 

Concerning claim 37, the DDI controller of Dara-Abrams comprises a GUI having a 
graphical element associated with a configuration command, whereby the graphical element is 
responsive to user input to operate the configuration command, and whereby the source code of 
the GUI references a code library, namely an API, which is associated with source code defining 
a CK and a CUI of a remote device, as is described above. It is understood that the CK may 
comprise a configuration parameter corresponding to a resource of the remote device, the 
parameter indicating for example, a current state of the resource (for example, see column 12, 
line 60 - column 13, line 34, and column 20, lines 14-44). As further described above, the CUI 
of the DDI target interfaces this configuration kernel with the GUI of the DDrcontroller; the 
code library, i.e. API, is linked with the GUI and are understood to be necessarily compiled with 
the GUI to create a device management application having the GUI with the CK and CUI 
running under the GUI, remotely from the DDI target. The DDI controller of Dara-Abrams is 
additionally understood to comprise a communications interface coupled with the DDI target to 
communicate a configuration update for the DDI target from the device management application 
(for example, see column 19, lines 53-67). Moreover, the DDI controller of Dara-Abrams is 
understood to comprise a processor coupled with memory to implement the device management 
application and coupled with the communications interface to provide a user-selected 
configuration command to the interface (see, for example, column 9, lines 42-63; and column 19, 
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lines 53-67). Consequently, the DDI controller of Dara-Abrams is considered an apparatus, like 
that of claim 37, which is for managing a remote device. 

Referring to claims 38 and 39, Dara-Abrams particularly discloses that an API is used 
within the source code of the DDI controller to communicate with the DDI target, specifically to 
send messages to the target, which result in the target executing various commands, and to 
receive status updates from the target, as is described above. As further described above, this 
API is considered a library comprising a plurality of functions for communicating with the 
remote DDI target. Each of these functions is considered a macro, like recited in claim 38, and a 
hook to a subroutine, like recited in claim 39. 

With respect to claim 40, Dara-Abrams discloses that the code for DDI target may be 
stored in ROM (see column 10, lines 18-27). It is therefore understood that source code for the 
DDI target CUI and CK may comprise firmware, developed for execution at the DDI target. The 
API of Dara-Abrams, which as described above communicates with the CUI and CK, is thus 
considered to include firmware code defining the CK and CUI, the firmware code developed for 
execution on the DDI target. 
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Claim Rejections - 35 USC §103 
The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

Claims 3 1, 36, and 41 are rejected under 35 U.S.C. 103(a) as being unpatentable over the 
U.S. Patent of Dara-Abrams, which is described above, and also over U.S. Patent No. 6,434,447, 
which is attributed to Shteyn. As described above, Dara-Abrams teaches a method like that 
recited in claim 22, and an article of manufacture like that of claim 32, whereby the source code 
for a GUI executing at a controller device is linked to the source code for an interface executing 
at a remote device, so that the user of the controller device may implement the GUI to configure 
a configuration parameter of the remote device. Dara-Abrams, however, does not explicitly 
disclose updating configuration commands at the remote device, like recited in claim 41. In 
other words, Dara-Abrams does not teach: identifying an updated configuration command in the 
configuration command set at the remote device; updating the source code for a command-set 
aware using interface at the remote device to reflect the updated configuration command in the 
configuration command set; and rebuilding the source code for the GUI at the controller device 
with the linked updated source code for the command-set aware user interface to result in an 
updated device management application having a graphical component to provide access to the 
updated configuration command, as is recited in each of claims 31 and 36. 

Like Dara-Abrams, Shteyn describes a GUI executing at a controller device, with which a 
user interacts in order to manage and control a remote device located over a network (see column 
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2, lines 1-39 of Shteyn, for example). Regarding the claimed invention, Shteyn particularly 
teaches introducing new features and functionalities to the remote device, and accordingly, 
modifying the source code of the remote device to accommodate such new features and 
functionality (for example, see column 7, lines 6-18). Shteyn similarly teaches updating the GUI 
of the controller device, and particularly adding new user interface elements, understandably to 
access the new features and functionalities of the remote device (again, see column 7, lines 6- 
18). 

Therefore, it would have been obvious to one of ordinary skill in the art, having the 
teachings of Dara-Abrams and Shteyn before him at the time the invention was made, to modify 
the system taught by Dara-Abrams, such that the source code of the remote device and the GUI 
of the controller device may be updated to add new features and functionality, as is taught by 
Shteyn. In other words, it would have been obvious to: add or update a configuration command 
in the configuration command set of the remote device of Dara-Abrams; to update the source 
code for the command-set aware user interface of the remote device to reflect the updated 
configuration command in the configuration command set; and to rebuild the source code for the 
command-set unaware GUI of the controller device with the linked updated source code for the 
command-set aware user interface to result in an updated device management application having 
a graphical component to provide access to the updated configuration command. It would have 
been advantageous to one of ordinary skill to utilize this combination because such an ability to 
be updated facilitates "development and market penetration" of the remote and controller 
devices, as is taught by Shteyn (see column 7, lines 6-18). 
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Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Blaine Basom whose telephone number is (571) 272-4044. The 
examiner can normally be reached on Monday through Friday, from 8:30 am to 5:30 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Cabeca can be reached on (571) 272-4048. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free V/? 
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